Situations can arise in a packet data network in which many senders require to send data to a single receiver. In the absence of an appropriate control mechanism, this can lead to both network and receiver overload. “Concast” is an example of a network layer service designed to address this issue, and is described in Calvert et al. “Concast: design and implementation of a new network service”, ICNP'99 (1999) pp. 335-344, and Calvert et al. “Concast: Design and Implementation of an Active Network Service”, Selected Areas in Communications (2001) vol. 19 (3) pp. 426-437. Concast and similar network layer services are characterised by the property of providing many-to-one communication where the receiver receives less traffic than the senders jointly send. In most implementations, this is achieved by actively merging messages at the tree joining points of the Concast network, where selected routers of the underlying IP network implement the Concast protocol. In a typical implementation, a Concast-enabled router recognises a Concast packet by inspecting the IP packet header for the presence of a Router Alert or Hop-by-Hop IP option.
An objective of the original Concast design was to reduce the risk of successful denial-of-service (DoS) attacks against receivers: where there are many senders and only one receiver, the senders can exhaust the receiver's resources unless the receiver has as much resources as all the senders put together. Concast seeks to reduce the amount of resources that the receiver requires by distributing some of the processing of the packets that would otherwise need to be performed by the receiver, to the intermediary nodes in the Concast network.
Typically, a Concast service is described in terms of a common receiver R, and a group G of senders S. The senders are structured in a tree with a number of internal tree nodes, each of which receives traffic from a number of senders and/or other tree nodes, and forwards it towards the receiver, either directly or via further tree nodes. In a typical Concast service, each tree node merges the traffic that it receives according to a merge specification (MS). Typically, the merge specification is supplied by the receiver and distributed through the tree as considered for example in U.S. Pat. No. 6,920,493. Typically the merge specification is distributed in the form of a binary-executable programme.
Concast may be advantageously used for example to relay acknowledgements from multiple clients receiving a multicast service from a server. In this case, each node of the Concast network merges acknowledgement messages together according to the MS, and forwards the merged messages on towards the multicast server.
While the presently proposed Concast services protect the receiver from DoS attacks by merging traffic within the network, they achieve this at the cost of opening some new DoS threats at the tree nodes (e.g. the possibility that a number of senders can be arranged to cause a network node to spend a considerable amount of resources in anticipation of further packets from the senders before completing a packet merge) and preventing senders from directly sending unmodified messages to the receiver. Furthermore, while the present Concast merge specifications are very flexible, they are also costly to implement as they require active hardware in the tree nodes, i.e. to allow the reprogramming of the tree nodes on demand, must be sufficiently generic so that they can execute for example Java byte code (see e.g. Calvert et al 2001, pages 5 and 7). In particular, a typical Concast service requires that the intermediary nodes decapsulate packets en route, merge packets arriving from different sources, and send packets containing information obtained through computation, as specified in the MS.